skip to main content

developerWorks  >  Open source | Java technology | Information Management  >

Build an Ajax application using Google Web Toolkit, Apache Derby, and Eclipse, Part 4: Deployment

Get your application and the Derby database up and running
Traduction pour créer une application Ajax utilisant Google Web Toolkit, Apache Derby, et Eclipse
Mise en place de votre application et de la base de données de Derby en service

developerWorks

Niveau : Intermédiaire

Noel Rappin (noelrappin@gmail.com), Senior Software Engineer, Motorola, Inc.

27 Feb 2007

Dans les trois articles passés de cette série, vous avez établi une application Web simple mais fonctionnelle en utilisant la trousse à outils de Web de Google (GWT). Jusqu'ici, vous avez éditer et corriger (debuguer) l'application en utilisant le mode accueilli (hosted) de GWT, qui permet de simuler un environnement de serveur web dans votre outil de développement Java™. Malheureusement, il est impraticable de lancer votre application de Web depuis Eclipse. Ainsi, en cet article, le quatrième de cette série, vous apprendrez comment déployer votre application de GWT dans un serveur d'application Web Java et obtiendrez des conseils sur l'emploi de la base de données d'Apache Derby pour conduire a bien le GWT.

Dans cet article, vous emploierez Apache Tomcat en tant que votre récipient de servlet d'exemple, parce qu'il est employé couramment et disponible gratuitement. D'autres récipients de servlet se comporteront pareillement. Vous vous déploierez souvent sur un serveur existant; mais sinon, les liens dans la section des Resources à la fin de cet d'article vous à indique l'endroit de téléchargement de Tomcat. Si vous exploitez le logiciel d'exploitation de Microsoft® Windows®, Tomcat a un installateur binaire pour Windows qui est relativement simple à utiliser. Si vous êtes sur un système Mac ou UNIX®, il y a une version compilée que vous pouvez extraire et placer dans un endroit commode (/usr/local est courant); après réglage de quelques variables d'environnement, vous serez bon pour tout lancer.

Compiler votre code client

Largement parlé, deux étapes pour déployer votre application de GWT dans Tomcat.

  1. Recueillir tous dossiers que vous aurez besoin et les mettrez où Tomcat peut les voir.
  2. Mettre au courant Tomcat de toutes actions du côté serveur que vous appelez de votre page GWT.

Le processus a quelques étapes de plus qu'il est souhaitable, et en date de cette écriture il n'y a aucune méthode officielle de l'automatiser. Je décris le processus manuel ici. Avant que vous lisiez ceci, sachez cependant qu'il peut exister un outil de déploiement pus robuste supportant de le déploiement.

  • Localiser le répertoire racine de votre installation de Tomcat. Un niveau plus bas à partir de cet annuaire vous verrez un sous-répertoire appelé les webapps. Chaque application fonctionnant dans le récipient de servlet de Tomcat (Tomcat servlet container) y possède son propre répertoire. Créer ainsi le repertoire appelé slicr dans des webapps. La structure d'une application Java côté serveur est placée par la norme de servlet, et tous les lanceurs de servlet devraient soutenir la même structure.
  • Dans votre répertoire de slicr, créer un sous-répertoire appelé WEB-INF -- et oui, la capitalisation est importante.
  • À votre répertoire slicr, déplacer vos pages GWT-compilées Javascript et vos classes Java normalement compilées. Je montrerai d'abord comment faire les classes Java.
  • Compiler votre code Java comme vous faites normalement, en utilisant votre environnement intégré de développement (IDE), Apache Ant, ou celui que vous souhaitez. Vous avez un couple d'options en ce moment :
    • L'option la plus rapide est de copier votre arbre entier des fichiers .class dans le sous-répertoire webapps/slicr/WEB-INF/classes de Tomcat, que Tomcat place automatiquement dans la variable classpath de votre répertoire webapps quand il est s'execute.
    • Alternativement, vous pourriez convertir les classes compilées en un fichier JAR à l'aide de l'outil de votre choix, et puis placez ce fichier JAR dans le dossier des webapps/slicer/WEB-INF/lib. Encore, Tomcat place le fichier JAR de ce répertoire dans votre variable classpath.

Compiler vos fichier GWT client

Après, compiler et déplacer vos fichiers GWT client. Puisque vous avez effectué la majeure partie de votre travail en mode accueilli, vous avez pu sauter cette étape explicitement jusqu'ici. La manière la plus rapide de compiler votre code est d'utiliser le bouton Compile de la console du mode accueillie. Mais il y a une autre manière qui pourrait être plus commode pour automatiser.

Dans la partie 1 de cette série, vous utilisiez le créateur d'application applicationCreator de GWT pour créer votre projet GWT. Lorsque, j'ai en passant fait référence « à un couple de scripts shell » créés en même temps que les fichier-projets de GWT mais sans rentrer dans les détails.

Un des fichiers shell créés s'appelle Slicr-compile. Dans Windows, le dossier a également une extension .cmd. (Génériquement, naturellement, c'est votre nomDuProjet-compile.) Appeler le fichier depuis une ligne de commande, ou le cliquer selon votre logiciel d'exploitation. Le script réfléchit pendant un moment avant de produire quelque chose de semblabe à:

Output will be written into ./www/com.ibm.examples.Slicr
Compilation succeeded


Ce qui se produit ici est que GWT compile tout votre code Java du côté client en code de Javascript. Le code côté client, par défaut, est tout le code dans le répertoire source du client de votre projet; cependant, vous pouvez explicitement changer ce dosier dans votre fichier .gwt.xml du projet en ajoutant une étiquette de la forme <source path=path/>, où le path est le chemin source que vous voulez ajouter. Noter que le chemin par défaut n'est plus inclus si vous ajoutez votre propre chemin, ainsi si vous voulez également le chemin par défaut, vous devez l'ajouter explicitement.

Le compilateur GWT convertit habituellement le code légal Java avec succès. Cependant, quelques articles poseront des problèmes. Les choses suivantes ont quelque chose de particulier:

  • Le code client de GWT doit être compatible avec Java 1.4. Cela ne signifie aucun génériques, aucun autoboxing, et aucun nouveau-modèle pour chaque (for-each) boucle. Supposément, la compatibilité de Java 1.5 est projetée dans un avenir proche.
  • Seulement un sous-ensemble minimal de la bibliothèque standard de Java est soutenu. Les librairies (bibliothèque) de classes soutenues sont limitées aux paquets java.util et java.lang packages. Pas tous ces paquets sont soutenus. En particulier, le paquet de java.lang.reflect n'est pas supporté. Comme vous avez vu dans la partie 2 cette série, ces restrictions que vous devez mettre des items comme le code de base de données dans d'autres parties de votre système.
  • Si vous employez des expressions régulières, elles ne sont interprétées au temps d'exécution en utilisant les règles de Javascript, pas les règles Java.
  • La sérialisation Java n'est pas supportée. Le mécanisme de prcédé à distance de GWT est employé à la place, comme discuté dans la partie 3 de cette série.
  • Il y a des différences dans la définition des nombres à virgules et des variables de type long. Des calculs qui exigent une sémantique stricte des nombres à virgule devraient être manipulés du côté du serveur.
  • Le compilateur GWT ignore Java les rapports (statements) assert. Aussi ignorés, les déclarations synchronisées synchronized, car l'interprète de Javascript ne permet pas la gestion des processsus (threading).

Etudier la sortie résultant de la compilation

Supposant que votre code de Java passe ces conditions et votre compilation est réussie, vous pouvez suivre la sortie du script de compilation et étudier le dossier ./www/com.ibm.examples.Slicr, suivant les indications de la liste 1. Certains de vos noms de dossier peuvent différer.


Liste 1. Sortie d'une compilation GWT
	
1A0A627040909C0818A7A71B13246DCD.cache.html
1A0A627040909C0818A7A71B13246DCD.cache.xml
587B8CC6CF487EBD41844000481528BF.cache.html
587B8CC6CF487EBD41844000481528BF.cache.xml
64AF143E1C4C5866446137A8C42B4609.cache.html
64AF143E1C4C5866446137A8C42B4609.cache.xml
B01955141995DDAD97AFC2941024CE4E.cache.html
B01955141995DDAD97AFC2941024CE4E.cache.xml
Slicr.html
com.ibm.examples.Slicr.nocache.html
gwt.js
history.html
tree_closed.gif
tree_open.gif
tree_white.gif

Which brings you to the files with the hex digit gobbledygook names. There are six HTML/XML pairs. Open the .html files and you'll see a lot of highly obfuscated JavaScript code, as shown in Listing 2, chosen at random.

Choses faciles d'abord: Slicr.html est la page HTML page que vous avez codé, copié ici directement à partir de votre répertoire public. N'importe quel élément du répertoire public sera placé ici. Les trois fichiers .gif sont, comme vous pourriez prévoir de leurs noms, utilisé par GWT pour faire le rendu de l'arbre des widgets. Puisque vous n'avez aucun arbre de widgets dans l'application de Slicr, vous pouvez supposer que GWT met toujours ces images dans votre rendu. Passons au reste des fichiers avec des noms prononçables, history.html a un certain code Javascript pour gèrer l'état et préserver le comportement du bouton Précédent. Les fichiers gwt.js et nocache.html contiennent tous les deux contiennent plus ou moins de code de zones fixes (boilerplate) conçu pour commencer et charger votre application de GWT correctement.

Ce qui vous ammène aux fichiers avec des noms de charabia de chiffre de sortilège. Il y a six paires de HTML/XML. Ouvrir les fichiers .html et vous verrez beaucoup de code Javascript fortement assombri (obfusqué), tel que la liste 2, choisie au hasard.


Liste 2. Code JavaScript
	
function ob(pb,qb){z();pb.F = qb;return pb;}
function rb(sb,tb,ub){z();sb.D = ub;sb.F = tb;return sb;}
function vb(){}
_ = vb.prototype = new f();_.jb = C;_.hb = E;_.i = 'java.lang.Throwable';
_.j = 1;_.D = null;_.F = null;function wb(xb){mb(xb);return xb;}
function yb(zb,Ab){ob(zb,Ab);return zb;}
function Bb(Cb,Db,Eb){rb(Cb,Db,Eb);return Cb;}

Je pense que c'est clair. C'est réellement votre gentil code et ordonné de Java compilé en code Javascript par le compilateur GWT. Il y a cinq paires de HTML/XML, une pour chacun des moteurs de rendu des pricncipaux navigateurs (browser) : Firefox/Gecko (vieilles et nouvelles versions), Internet Explorer de Windows, Opéra, et Safari. Les fichiers XML contrôlent le typage de quelques données de sorte que les types de données corrects soient employés pour ce moteur. L'obscurcissement (obfuscation) est là pour comprimer la taille du dossier des textes qui doit être envoyé au navigateur. Quand un récupère la page de GWT depuis un navigateur, le code Javascript dans les pages de zones fixes recherche et charge automatiquement la version correcte de votre code pour le navigateur de l'utilisateur.

Pour déployer vos pages GWT, tous ces fichiers du répertoire www/com.ibm.examples.Slicr doivent être copiés dans le dossier Home/webapps/slicr de Tomcat. Ce s'occupe du côté de client, maintenant occupons nous du côté serveur.



Back to top


Deployer le côté serveur

Si vous avez fait le développement de servlet avant, alors la présente partie du processus de GWT devrait être familière. Le code de serveur-côté que vous avez écrit est juste une autre application de servlet et est déployé en utilisant la norme de Servlet.

D'abord, vous devez compiler tout votre code de Java en utilisant un compilateur Java plat et ordinaire. A ce moment, vous avez deux options :

  • Vous pouvez placer tous les fichiers .class dans le répertoire Home/webapps/WEB-INF/classes de Tomcat.
  • Alternativement, vous pouvez combiner tous vos fichiers .class dans un fichier .jar et placer ce fichier dans le dossier Home/webapps/WEB-INF/lib de Tomcat.

Le code compilé devrait inclure le code de côté client que vous avez déjà compilé en utilisant GWT -- rappeler vous, vous emploient certaines de ces classes côté client sur le côté serveur pour faciliter le transfert de données.

Vous devez également mettre toutes les bibliothèques tierces que vous employez dans le même dossier /lib. Cet dossier inclut toujours le fichier gwt-servlet.jar, qui lui-même est inclus avec la distribution de GWT. Ce fichier contient tous les fichiers GWT utilisateur nécessaires à votre application.

Note : La distribution originale de GWT n'inclue pas ce fichier. Cependant, vous pouvez encore voir les instructions de déploiement de Web qui impliquent d'entailler (hacking) le fichier gwt-user.jar pour enlever les classes de servlet qui interféreraient Tomcat. Si votre distribution de GWT est à jour, cette étape n'est pas nécessaire.

Dans ce cas-ci, vous avez également besoin du fichier de derby.jar, qui fait partie de la distribution de Derby et qui contient les classes de base de données de Derby dont vous avez besoin. Si vous voulez transférer la base de données de Derby sans perdre les données des garnitures, placer simplement la base de données d'annuaire de slicr que Derby a créée dans la partie 2 de cette série. (Si vous suiviez les directions dans la partie 2, ce répertoire devrait être sous votre niveau supérieur de projet au même niveau que le répertoir /src.) Il n'importe pas où vous mettez le dossier, mais la ligne dans la classe ToppingServiceImpl qui définit l'URL de JDBC pour Derby doit refléter cet endroit :

public static final String PROTOCOL =
"jdbc:derby:[LOCATION OF SLICR DB DIRECTORY]/slicr;";


J'ai placé ma base de données de Derby à l'intérieur du dossier webapps/slicr de Tomcat, au même niveau que l'annuaire de WEB-INF, ainsi mon code ressemble à ceci :

public static final String PROTOCOL =
"jdbc:derby:/usr/local/apache-tomcat-5.5.20/webapps/slicr/slicr;";

Definir vos appels côté serveur dans web.xml

Après que votre code soit visible par le récipient (container) servlet de Tomcat, vous devez également spécifiquement définir tous appels côté serveur de votre application GWT afin que le server web de Tomcat comprenne. Faire cela implique ainsi de définir ces appels côté serveur en tant que servlets dans le web.xml de l'application Tomcat. Essentiellement, pour chaque servlet définie dans votre fichier gwt.xml comme ceci :

<servlet path="/toppings" class="com.ibm.examples.server.ToppingServiceImpl"/>

vous devez créer un <servlet> et une étiquette de <servlet-mapping> dans le fichier web.xml. La lsite 3 exposie le fichier web.xml en entier pour votre projet GWT, contenant les deux étiquettes pour votre servlet ToppngService.


Liste 3. Web.xml
	
<?xml version="1.0" encoding="UTF-8"?> 
<web-app> 
    <servlet> 
        <servlet-name>ToppingService</servlet-name> 
        <servlet-class>
            com.ibm.examples.server.ToppingServiceImpl
        </servlet-class> 
    </servlet> 
    <servlet-mapping> 
        <servlet-name>ToppingService</servlet-name> 
        <url-pattern>/toppings</url-pattern> 
    </servlet-mapping> 
</web-app>    

Dans le fichier web.xml, les deux informations fournies dans votre fichier gwt.xml sont coupées en deux étiquettes différentes, en tant qu'élément de l'initiative Java faire-tout-comme-bavard-comme-possible (make-everything-as-verbose-as-possible). L'étiquette <servlet> prend le nom entièrement qualifié de classe pour le servlet, et l'étiquette <servlet-mapping> prend le nom d'URL comme vous l'avez défini dans le fichier GWT. Les deux sont unifiés par l'attribut commun servlet-name, qui peut être quelque chose que vous aimez tant que vous êtes conformé. Cependant, il est probablement meilleur d'employer une convention d'appellation simple, telle que le nom GWT du réel service.

La création de ce dossier est, naturellement, éminemment automatisable par tout un nombre de méthodes s'étendant de la manipulation pure des textes à la manipulation du modèle d'objet de document de XML (DOM). Quand vous avez écrit ce fichier, placer le à l'intérieur de votre répertoir WEB-INF de Tomcat. A ce moment, le déploiement de Slicr est complet, et vous pouvez tester l'application en lançant Tomcat et en tapant l'URL au clavier, qui sera quelque chose comme http://localhost:8080/slicr/Slicr.html. Si réussi, vous verrez la page de Slicr juste comme elle était après la partie 3 de cette série.

Dépannage des problèmes de déploiement

Problème Cause
Vous ne voyez rien du tout quand vous saisissez l'URL.

Très probablement la cause est que la page de Slicr.html n'est pas au bon endroit. Si vous obtenez seulement Welcome to Slicr mais à aucun des widgets de GWT, vous avez très probablement placé incorrectement les fichiers Javascript de GWT.

Vous voyez le côté gauche de la page mais de rien sur le panneau des garnitures excepté les en-têtes.

Ceci signifie que l'appel de serveur a échoué. Vous devrez consulter les logs de Tomcat pour diagnostiquer ce problème correctement (ou alternativement, changer la méthode OnFailure() dans le rappel de service pour imprimer un message d'erreur au panneu). La première possibilité est que vous n'avez pas vos fichiers de classe Java Slicr en place, qui empêche le chargement du servlet. (Ceci pourrait également se produire si le fichier de web.xml n'est pas établi correctement.)

Vous rencontrez un échec de Derby. S'assurer que les l'URL de JDBC corresponde à l'endroit du dossier des données de Derby.

Maintenant que j'ai décrit ce processus entier, vous pouvez voir que bien qu'il y ait beaucoup d'étapes, aucune de elles n'est particulièrement complexe. Je recommande vivement d'automatiser votre déploiement autant que possible en employant des scripts, des taches Ant, ou tous les autres moyens qui fonctionnent pour votre projet. Vous verrez un exemple dans les Resources, et le différents IDEs Java ajoute un plus au support de GWT, y compris le déploiement. Avoir un un bouton de déploiement vous esquive de beaucoup de maux de tête.



Back to top


Explorer plus

Share this...

digg Digg this story
del.icio.us Post to del.icio.us
Slashdot Slashdot it!

Au cours de cette série d'article sur GWT, vous avez établi une application Web simple qui démontre comment vous pouvez employer GWT avec une base de données principale pour créer une application Web robuste avec le comportement de client riche. Même après quatre articles, vous avez seulement survolé la surface de ce que GWT doit offrir. Fonctionnalités puissantes -- comme les test d'intégration JUnit, employer d'autres services Web par le Javascript a arrangé l'échange de données de la notation d'objet (JSON), et les nouvelles fonctionnalités d'internationalisation de GWT -- vous permet de gagner du temps. Le développement de GWT continue à se développer, et de nouvelles fonctionnalités et outils sont ajoutés à toute heure. J'espère que vous pourrez y jeter un coup d'oeil et trouver les outils dont vous avez besoin pour créer l'application que vous voulez.

Resources

Article traduit en Français

Original English article
Learn

Get products and technologies

Discuss


A propos de l'auteur

Noel Rappin, a Ph.D. from the Graphics, Visualization, and Usability Center at the Georgia Institute of Technology, is a senior software engineer at Motorola. He is also the coauthor of wxPython in Action and Jython Essentials. You can check out Noel's blog at 10printhello.blogspot.com.